SSL 인증서 구성과 작동 원리 가이드

SSL 인증서의 구성 요소와 역할

전체 구조 개요

SSL 인증서는 신뢰 검증과 실제 암호화 통신 두 단계로 나누어 작동합니다.

graph TB
    subgraph "1단계: 신뢰 검증 (1회성)"
        A[Root CA] -->|서명| B[Intermediate CA]
        B -->|서명| C[도메인 인증서
Public Key 포함]
    end
    
    subgraph "2단계: 실제 통신 (지속적)"
        D[Public Key] -->|암호화| E[세션키 교환]
        F[Private Key] -->|복호화| E
        E --> G[대칭키 암호화 통신]
    end
    
    C -.-> D

구성 요소별 상세 역할

구성요소 파일명 예시 역할 사용 시점
Private Key domain.key 세션키 복호화, 서버 신원 증명 핸드셰이크 시
Public Key/Certificate domain.crt 도메인 소유권 증명, 세션키 암호화 핸드셰이크 시
Certificate Chain Chain_RootCA_Bundle.crt 서버 신뢰성 보증 연결 초기 1회 검증

SSL/TLS 통신 과정 상세

1단계: 신뢰 검증 (Chain + Root CA)

브라우저는 다음 순서로 서버의 신뢰성을 검증합니다:

  1. 서버로부터 도메인 인증서와 인증서 체인을 수신
  2. 인증서 체인을 검증하여 Root CA → Intermediate CA → 도메인 인증서 연결 확인
  3. Root CA가 브라우저의 신뢰 저장소에 포함되어 있는지 확인
  4. 전체 체인이 유효한 경우 해당 서버를 신뢰할 수 있다고 판단

검증 완료 시 브라우저에 녹색 자물쇠가 표시됩니다.

2단계: 실제 암호화 통신 (Public + Private Key)

신뢰 검증 완료 후 실제 암호화 통신이 시작됩니다:

  1. 클라이언트가 랜덤한 세션키를 생성
  2. 클라이언트가 서버의 Public Key로 세션키를 암호화하여 전송
  3. 서버가 Private Key로 암호화된 세션키를 복호화
  4. 서버가 복호화 성공을 클라이언트에게 응답
  5. 양측이 세션키를 사용한 대칭 암호화 통신을 시작

이후 모든 데이터는 빠른 대칭 암호화 방식으로 안전하게 전송됩니다.

SSL 핸드셰이크 과정

sequenceDiagram
    participant B as 브라우저
    participant S as 서버
    
    Note over B,S: 1단계: 신뢰 검증
    B->>S: 연결 요청 (Client Hello)
    S->>B: 인증서 전송 (Public Key + Chain 포함)
    B->>B: 인증서 체인 검증 수행
    Note over B: 서버 신뢰성 확인 완료
    
    Note over B,S: 2단계: 암호화 통신 시작
    B->>S: Public Key로 암호화된 세션키 전송
    S->>S: Private Key로 세션키 복호화
    S->>B: 복호화 성공 응답
    
    Note over B,S: 3단계: 대칭키 통신
    B->>S: 암호화된 요청 데이터
    S->>B: 암호화된 응답 데이터

인증서 체인의 보증 구조

체인 파일 내부 구성

인증서 체인 파일은 다음과 같은 구조로 구성됩니다:

-----BEGIN CERTIFICATE-----
[Intermediate CA Certificate]
도메인 인증서에 대한 직접적인 보증을 제공하는 중간 인증기관
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
[Root CA Certificate]
중간 인증기관에 대한 보증을 제공하는 최상위 인증기관
브라우저의 신뢰 저장소에 미리 포함되어 있음
-----END CERTIFICATE-----

보증 체계

Root CA (브라우저가 사전에 신뢰)
    ↓ 디지털 서명
Intermediate CA (Root CA가 보증)
    ↓ 디지털 서명
Domain Certificate (Intermediate CA가 보증)
    ↓ 포함
Public Key (실제 암호화에 사용)

신뢰 체인의 검증 과정

브라우저는 다음 단계를 통해 인증서의 신뢰성을 검증합니다:

  1. 도메인 인증서의 서명자 확인 (Intermediate CA)
  2. Intermediate CA 인증서의 서명자 확인 (Root CA)
  3. Root CA가 브라우저 신뢰 저장소에 포함되어 있는지 확인
  4. 전체 체인의 연결성 검증
  5. 각 인증서의 유효 기간 확인

모든 검증 단계를 통과하면 브라우저는 녹색 자물쇠를 표시합니다.

개인키(Private Key)의 중요성

개인키가 서버에 필요한 이유

  1. 서버 신원 증명 클라이언트가 서버의 진위를 확인하기 위해 암호화된 챌린지를 전송하면, 서버는 해당 도메인 인증서와 쌍을 이루는 Private Key를 보유하고 있음을 증명해야 합니다.

  2. 실시간 암호화 통신 클라이언트가 Public Key로 암호화한 세션키를 서버가 Private Key로 복호화함으로써 안전한 통신 채널을 구축합니다.

  3. 지속적 보안 통신 모든 HTTPS 요청에 대해 Private Key를 사용한 SSL 종료(SSL Termination) 과정이 수행됩니다.

Private Key 부재 시의 문제점

Private Key가 없는 경우 서버는 클라이언트가 전송한 암호화된 세션키를 복호화할 수 없으며, 이로 인해 SSL/TLS 연결이 실패하고 브라우저에서 연결 거부 오류가 발생합니다.

역할 분리: 보증 vs 실제 통신

보증 단계 (Chain + Root CA)

통신 단계 (Public + Private Key)

구조적 분리의 의미

인증서 체인은 신원 확인 과정에서만 사용되며, 실제 데이터 암호화는 Public/Private Key 쌍이 담당합니다. 이는 신뢰 검증과 암호화 통신의 역할을 명확히 분리한 구조입니다.

암호화 방식의 효율성

하이브리드 암호화 시스템의 필요성

성능상의 고려사항

공개키 암호화 (RSA 2048bit): 연산 복잡도가 높아 처리 속도가 느림
대칭키 암호화 (AES 256bit): 연산이 단순하여 처리 속도가 빠름

해결 방안:
1. 연결 초기에만 공개키 암호화로 세션키 교환 (보안성 확보)
2. 이후 모든 통신은 세션키 기반 대칭 암호화 (효율성 확보)

보안상의 고려사항

역할 분담:
- 신뢰 검증: 통신 상대방의 신원 확인
- 실제 통신: 안전한 데이터 전송 방법 구현

핵심 요약

SSL 인증서는 두 가지 독립적인 기능을 수행합니다:

1. 신뢰 검증 (Chain + Root CA)

2. 실제 암호화 통신 (Public + Private Key)